Paths through the Internet vary widely in the quality of service they provide. The traditional best-effort model of the Internet does not differentiate between traffic flow that is generated by different hosts. As traffic flow varies, the network provides the best service it can. There are no controls for guarantying a high level of service for some traffic flow and not for others.
Although the Internet itself has no direct controls for optimizing paths for particular applications or users, the Internet Protocol (IP) does provide a header that contains bits for specifying Quality of Service (QoS) information. The value of the QoS information is intended to denote how the network should treat packets of data with regard to throughput, delay, reliability, and cost. QoS information may be conveyed, for example, in layer 2 MAC frame packets as defined in IEEE 802.1p/Q (via the priority field) or in layer 3 IP packets (via the TOS field). The TOS facility, for example, was outlined in Request for Comment (RFC) 791 (“Internet Protocol,” September 1981), authored by the Internet Engineering Task Force (IETF) and available via the Internet at http://www.ietf.org. Although the TOS facility has been a part of the IP specification for quite some time, few attempts have been made to utilized it until recently. Recent RFCs from IETF, such as RFC 1633 (“Integrated Services in the Internet Architecture: An Overview”) and RFC 2475 (“An Architecture for Differentiated Services”) are beginning to define how packets should be routed.
FIG. 1 illustrates a conventional communications system including a multiple-Virtual-Circuit (multi-VC) bridge 115 connecting one or more data processing systems 110 to network devices 130, 132, 134 in, for example, a Wide Area Network (WAN) 140. The data processing systems 110 produce and transmit packets of data to the multi-VC bridge via one or more physical or wireless communications paths. The data processing systems 110 may be different devices, such as computers, voice-over-IP phones, or set-top boxes.
The multi-VC bridge 115 is responsible for receiving packets of data from the data processing systems 110 and forwarding them to their destinations over Asynchronous Transfer Mode (ATM) Permanent Virtual Circuits (PVCs) 120, 122, 124 in an ATM network. As illustrated in FIG. 1, each PVC 120, 122, 124 is associated with a specific network device 130, 132, 134, each having a unique Media Access Control (MAC) address. In this configuration, the multi-VC bridge 115 monitors packets of data from the WAN 140 by snooping (i.e., examining) each packet of data for its source MAC address and storing the learned addresses in a mapping table. When packets are transmitted to the WAN 140, the multi-VC bridge 115 examines the MAC destination address, looks up that address to determine which PVC corresponds to the address, and then forwards the packet of data over that PVC.
FIG. 2 illustrates a second communications system 200 suitable for implementing the present invention. Communications system 200 includes multiple PVCs 120, 122, 124 connecting a multi-VC bridge 115 and to a WAN 140. In communications system 200, the PVCs 120, 122, 124 terminate on a single piece network equipment, such as a broadband remote access server (BRAS) 150. The BRAS 150 is responsible for forwarding the packets of data to their appropriate destination equipment represented by 160, 162, and 164. The BRAS 150 typically has a single MAC address associated with it and all of the PVC's terminate at that MAC address. In such a configuration, the multi-VC bridge 300 may choose from among different PVCs when forwarding packets. As a result, a need exists for an improved multi-VC bridge that intelligently chooses from available PVCs to facilitate the provision of differentiated quality of service.